For many years, the lack of a health data exchange process resulted in poor care coordination and patient performance. Now, we have revolutionary standards that allow better patient care, reduce the cost of care, improve healthcare efficiency, and exchange health data securely.
HL7 standards and FHIR are widely used within global healthcare. So it’s no wonder the FHIR vs HL7 topic is popular. In our previous publications, we discussed the importance of seamless data exchange and described how to facilitate healthcare interoperability.
Today, we will talk you through the most transformative healthcare standards and define the difference between FHIR and HL7. The development of health data standards has led the world to an understanding of health data accessibility and exchangeability significance and allowed us to build a modern healthcare ecosystem based on interoperability principles.
What Is the Difference Between HL7 and FHIR? A Deeper Dive
What Is HL7?
Health Level 7 International is a not-for-profit ANSI-accredited standards-developing organization. Its goal is to develop standards and provide a framework for exchanging, integrating, and retrieving health data that supports clinical data practices and management, delivery, and evaluation of health services.
HL7 (Health Level Seven) is the organization that created HL7 V2, HL7 V3, CDA, the HL7 FHIR standard, etc. Most of the standards are widely used around the world today.
Most of the standards defined by HL7 are widely used worldwide by various healthcare providers to ensure the simplicity of data transfer. Standards developed by HL7 help minimize administrative burdens and focus on quality healthcare delivery.
Standardization of healthcare is necessary to achieve a uniform mechanism of health information processing and exchange. HL7 specifies the number of healthcare standards that define rules for communication between various health systems.
The newer standard of HL7 targets implementers, not clinicians. Such an approach considerably simplifies implementation and stimulates developers to create new healthcare IT solutions.
HL7 (V2, V3, and CDA) and FHIR. A Side-by-Side Comparison
V2 is a legacy system that defines messaging only. The standard doesn’t cover data storage and interoperability problems. The V2 message has an outdated design that does not help the scalability and is impossible to read for non-V2 experts.
V3 is HL7’s attempt to build an electronic healthcare model with rigid types and XML-based messaging. The HL7 V3 introduces the concept of RIM (Reference Information Model), which represents a static model of healthcare information. It provides messages, terminologies, and data types.
FHIR is the implementers-focused standard that relies on the open-source paradigm. It is published on the page https://hl7.org/fhir/. Unlike previous healthcare standards, it is available for study and use. Accessibility of the standard greatly contributes to the community interest and involves developers in standard development and testing.
We’ve compiled brief descriptions of the critical characteristics of all standards released by the HL7 organization for achieving interoperability to clarify the difference between HL7 and FHIR.
| Feature | HL7 V2 | HL7 V3 | HL7 CDA | FHIR |
| Overview | Widely used, older standard for data transmission between systems | Complex, highly structured data exchange standard | Markup standard for defining a structure of clinical documents | Modern data exchange standard with a flexible elements and web-based approach |
| Data Format | text-pipe-and-hats messages | XML-based | XML, document-oriented | JSON, XML, RDF |
| Interoperability | Limited, version-specific | Present but difficult to achieve | High for document exchange | High, flexible |
| Implementation Complexity | Lower, due to simplicity | High, due to complexity | Moderate | Lower, implementor-friendly |
| Flexibility | Low | Moderate | High for documents | High, modular |
| Use Case | Admit discharge transfer patients, medical prescriptions, measurement results, etc. | CDA is the most commonly used component of the V3 standard (for clinical doc’s exchange) | Clinical documents exchange between patients and caregivers | Cover all common healthcare use cases. Used for exchange of such documents as ab test results, clinical letters, scans, etc. |
| Adoption Rate | High in legacy | Very low | Moderate | Rapidly growing |
| Resources (technology availability) | Work for exchange between systems within an organization and provides enterprise-level interoperability | Implementation of the common data model (RIM) is mandatory, making it too complex and unprofitable | An essential component of data exchange in healthcare. May take months to learn | Appeal to web-savvy developers but may require training costs and additional time or the help of certified FHIR experts |
There’s no universal choice between FHIR and other HL7 standards, but there are several aspects to consider before adopting any of the healthcare data standards by HL7. In short, base your decision on your organization’s unique requirements, existing infrastructure, and long-term goals. Let’s get to the detailed characteristics and message examples of V2, V3, CDA, and FHIR.
Health Level Seven Version 2 (V2) is a messaging standard that allows communication between various systems within a hospital. HL7 developed this standard back in 1989 to ensure enterprise-level interoperability in healthcare. It is the world’s most widely implemented healthcare standard—95% of US healthcare organizations use HL7 V2.x.
Technical characteristics
| Structure | Message built with text, pipes, and hats |
| Purpose | Medical record and events exchange |
| Learning | Has a big learning curve |
| Platforms support | EMR, EHR, HIS, LIMS |
| Extensibility | Non-extensible |
| Interoperability type | Syntactic |
| Security | On the transmission layer |
| Code systems | Limited support to ICD, LOINC, DICOM |
| Compatibility | Backward compatible with all V2 versions |
| Samples | Available |
| Required tools | HL7 Message Parser |
Use cases: HL7 V2 messages allow data transmission between systems (e.g., admit discharge transfer patients, medical prescriptions, financial transactions, observation results, measurement results).
Let’s look at the HL7 ORU (Observation Result) message. Clinical system A sends the Observation Result message in response to a request created in clinical system A. ORU messages include the following types of observations: lab results, EKG results, study reports, symptoms, allergies, etc.
Message Structure: HL7 V2 message consists of texts, pipes, and hats.
MSH|^~\&|MESA_RPT_MGR|EAST_RADIOLOGY|iFW|XYZ|||ORU^R01|MESA3b|P|2.4||||||||
PID|||CR3^^^ADT1||CRTHREE^PAUL|||||||||||||PatientAcct||||||||||||
PV1||1|CE||||12345^SMITH^BARON^H|||||||||||
OBR|||||||20010501141500.0000||||||||||||||||||F||||||||||||||||||
OBX|1|HD|SR Instance UID||1.113654.1.2001.30.2.1||||||F||||||
OBX|2|TX|SR Text||Radiology Report History Cough Findings PA evaluation of the chest demonstrates the lungs to be expanded and clear. Conclusions Normal PA chest x-ray.||||||F||||||
CTI|study1|^1|^10_EP1The HL7 V2 message includes the following segments:
- The Message Header (MSH) – a required segment that cannot be excluded. It consists of data about the message sender and recipient.
- The Patient Identification (PID) – segment includes demographic data of a specific patient (identifier, name, date of birth). PID segment is required.
- Patient Visit (PV1) – a required message segment with patient visit details (visit ID, caregiver, servicing facility).
- The Observation Request (OBR) – a required segment that allows the identification of the observation ordered for Observation Result message generation.
- The Observation Result (OBX) – an optional segment that includes information about the observation result. This segment identifies the type of observation, its result, the date of observation, and observation-related information. The segment can be repeated.
- Clinical Trial Identification (CTI) – this segment links the result to a clinical trial. This segment is optional and can be repeated. The segments contain the clinical trial identification information, phase, and time point of the study.
The HL7 V2 standard is suitable for communication between government healthcare systems with no option to store data in databases. This type of messaging works for data transmission between medical systems in one organization and cannot scale across different organizations.
In the early 2000s, the recognition of data importance in the context of healthcare workflows became obvious and pushed HL7 to develop a more comprehensive messaging standard.
As a result, they introduced the Health Level Seven Version 3 (V3) standard, which represents all the data needed for healthcare interoperability. This standard is based on a common Reference Information Model (RIM), which constitutes a universal reference model for all information that needs representation within healthcare.
Reference Information Model example
All RIMs implementation is obligatory for all users of the third version of HL7, which makes the implementation process too complex and costly.
Technical characteristics
| Structure | Structured message in XML format |
| Purpose | Medical record and events exchange |
| Learning | Takes months to learn |
| Platforms support | EMR, EHR, HIS, LIMS |
| Extensibility | Non-extensible |
| Interoperability type | Syntactic and Semantic |
| Security | On the transmission layer |
| Code systems | Allows ICD object embedding; LOINC and DICOM can be embedded in a RIM object. |
| Samples | – |
| Required tools | Model compiler |
Use cases: The HL7 V3 standard was developed in response to data exchange gaps that could not be fixed with HL7 V2. This standard was meant to cover the same use cases as the previous HL7 standard and address communication issues within healthcare.
Message example:
<observationEvent>
<id root="2.16.840.1.113883.19.1122.4" extension="1045813"
assigningAuthorityName="GHH LAB Filler Orders"/>
<code code="1554-5" codeSystemName="LN"
codeSystem="2.16.840.1.113883.6.1"
displayName="GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN"/>
<statusCode code="completed"/>
<effectiveTime value="200202150730"/>
<priorityCode code="R"/>
<confidentialityCode code="N"
codeSystem="2.16.840.1.113883.5.25"/>
<value xsi:type="PQ" value="182" unit="mg/dL"/>
<interpretationCode code="H"/>
<referenceRange>
<interpretationRange>
<value xsi:type="IVL_PQ">
<low value="70" unit="mg/dL"/>
<high value="105" unit="mg/dL"/>
</value>
<interpretationCode code="N"/>
</interpretationRange>
</referenceRange>The HL7 V3 message consists of three layers:
- Transport Wrapper – this level contains all the message transport information, such as the data about the sender and receiver and systems interaction ID message.
- Event Wrapper – contains information about the event, defines its type, trigger, responsive parties, and the date on which the event occurred.
- Domain Payload – the core layer of the V3 message that includes the administrative and clinical data.
Thanks to the RIM, the third version of the standard covers every possible healthcare use case imaginable, which made the V3 an unbearably complex and cost-prohibitive standard with a big learning curve.
CDA (Clinical Document Architecture) is a flavor of HL7 V3. CDA is a document markup standard that defines the structure of clinical documents to establish the exchange of clinical data between patients and caregivers. CDA defines the following characteristics for all clinical documents: 1) Persistence, 2) Stewardship, 3) Potential for authentication, 4) Context, 5) Wholeness, and 6) Human readability.
Technical characteristics
| Structure | XML document |
| Purpose | Clinical document exchange |
| Learning | Takes months to learn |
| Platforms support | EMR, EHR, HIS, LIMS |
| Extensibility | Non-extensible |
| Interoperability type | Syntactic and Semantic |
| Security | On the transmission layer |
| Code systems | Allows ICD object embedding; LOINC and DICOM can be embedded in a RIM object. |
| Samples | – |
| Required tools | Model compiler |
Use Cases: The Clinical Document Architecture is used to exchange data about the patient. A typical CDA includes text, images, sounds, and other content. CDAs are widely used across healthcare within hospitals, immunization clinics, and other types of healthcare organizations.
Message example:
<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3" xmlns:cda="urn:hl7-org:v3" xmlns:sdtc="urn:hl7-org:sdtc">
<!-- ** CDA Header ** -->
<realmCode code="US"/>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<!-- US General Header Template -->
<templateId root="2.16.840.1.113883.10.20.22.1.1" extension="2014-06-09"/>
<!-- *** Note: The next templateId, code and title will differ depending on what type of document is being sent. *** -->
<templateId root="2.16.840.1.113883.10.20.22.1.8" extension="2014-06-09"/>
<id extension="TT988" root="2.16.840.1.113883.19.5.99999.1"/>
<code codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" code="18842-5" displayName="Discharge summarization note"/>
<title>Community Health and Hospitals: Discharge Summary</title>
<effectiveTime value="201409171904-0500"/>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<languageCode code="en-US"/>
<setId extension="sTT988" root="2.16.840.1.113883.19.5.99999.19"/>
<versionNumber value="1"/>The full-size example is available in the CDA examples repository on GitHub.
CDA Document Structure:
- Header – includes metadata and sets the context for the document. The information in the header covers the CDA creation date, its creator, organization, and the related patient.
- Body – contains human-readable and machine-readable content for the document in non-XML format. The body represents the authenticated clinical report.
- Section(s) – a combination of one narrative block and zero-to-many entries.
- Narrative Block(s) – a text section representing the content for viewing.
- Entries – discrete data for machine processing.
CDA includes all the patient-related information, including medical history, medications, insurance, lab results, and more. A clinical document includes detailed information about a patient that healthcare providers can freely exchange.
What Is FHIR?
FHIR is the standard developed by Health Level Seven International, as well as other standards whose names start with HL7. FHIR is an innovative healthcare standard that summarizes strong points, fills gaps in previous HL7 standards, and employs existing web technologies that simplify its implementation.
Its goal is to speed up and simplify the development of IT solutions that address healthcare interoperability challenges. This standard is a collection of specifications that define its elements and data formats.
FHIR profiles are a key feature of the FHIR standard, allowing for the creation of specialized data definitions and constraints to support specific use cases and interoperability requirements within the healthcare industry.FHIR is based on HTTP protocol and supports the RESTful API approach. So, what is the FHIR standard? REST is a widely used exchange standard that defines a set of operations within an application programming interface, such as create, read, update, delete, and more. REST APIs simplify data migration between servers and separate clients from a server. That improves the scalability of a FHIR data model. The FHIR standard enables the development of tools for fast access and exchange of EHRs data.
Technical characteristics
| Structure | Messages in XML/JSON; access is based on REST API |
| Purpose | Health data exchange |
| Training | Takes weeks to learn and adopt |
| Platforms support | EMR, EHR, HIS, LIMS applications |
| Extensibility | Features extensible resources |
| Interoperability type | Syntactic and Semantic |
| Security | Built in the transmission layer; allows SSL usage |
| Code systems | Allows ICD object embedding; LOINC and DICOM can be embedded in a RIM object. |
| Samples | A catalog of samples is available on the FHIR website. |
| Required tools | – |
Use cases:
An FHIR resource or a combination of resources can cover the most common use cases within healthcare. FHIR provides a seamless exchange of lab test results, clinical letters, scans, and other documents that affect the patient’s outcome.
FHIR functionality is based on REST API, which defines a set of operations on a resource. CRUD operations are the most commonly used for interaction with an FHIR resource within an FHIR server.
Let’s take a look at the structure of the FHIR Diagnostic report resource. A report usually includes the actual text report, images, and codes. The Diagnostic report resource allows laboratory reports (e.g., clinical chemistry), imaging and radiology (x-ray, CT, MRI), pathology, gastroenterology reports, and other diagnostics.
In the case of lab test results, the resource allows sharing information about a laboratory test and the specimen. You can find more information on messaging using FHIR Resources at hl7.org/fhir to compare FHIR to HL7 V2 messages.
Message example:
{
"resourceType" : "DiagnosticReport",
"id" : "ultrasound",
"text" : {
"status" : "generated",
"div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\"><h2><span title=\"Codes: {http://snomed.info/sct 45036003}\">Abdominal Ultrasound</span> (<span title=\"Codes: {http://snomed.info/sct 394914008}, {http://terminology.hl7.org/CodeSystem/v2-0074 RAD}\">Radiology</span>) </h2><table class=\"grid\"><tr><td>Subject</td><td><b>Jim </b> male, DoB: 1974-12-25 ( Medical record number: 12345 (use: USUAL, period: 2001-05-06 --> (ongoing)))</td></tr><tr><td>When For</td><td>2012-12-01T12:00:00+01:00</td></tr><tr><td>Reported</td><td>2012-12-01T12:00:00+01:00</td></tr></table><p><b>Report Details</b></p><p>Unremarkable study</p></div>"
},
"status" : "final",
"category" : [{
"coding" : [{
"system" : "http://snomed.info/sct",
"code" : "394914008",
"display" : "Radiology"
},
{
"system" : "http://terminology.hl7.org/CodeSystem/v2-0074",
"code" : "RAD"
}]
}],
"code" : {
"coding" : [{
"system" : "http://snomed.info/sct",
"code" : "45036003",
"display" : "Ultrasonography of abdomen"
}],
"text" : "Abdominal Ultrasound"
},
"subject" : {
"reference" : "Patient/example"
},
"effectiveDateTime" : "2012-12-01T12:00:00+01:00",
"issued" : "2012-12-01T12:00:00+01:00",
"performer" : [{
"reference" : "Practitioner/example"
}],
"media" : [{
"comment" : "A comment about the image",
"link" : {
"reference" : "DocumentReference/1.2.840.11361907579238403408700.3.1.04.19970327150033", "display" : "WADO example image"
}
}],
"conclusion" : "Unremarkable study"
}A resource consists of four parts:
- Metadata – contains the resource details (date of the resource creation, resource version ID)
- Narrative – the HTML representation of the resource’s content; the human-readable summary.
- Extensions – the part of a resource used to add data that initially is not a part of a defined resource structure.
- Standard data – the block includes the medical record number, patient name, gender, birth date, info about the care provider, etc.
As you can see, an FHIR resource has a user-friendly structure. All the data, including coded elements, are represented in human-readable form. The standard leverages existing web technologies, encouraging developers to create new healthcare IT solutions.
What Are the Similarities Between HL7 and FHIR?
HL7 and FHIR standards are parts of one family of standards. HL7 and FHIR protocols vary since FHIR sticks to commonly used web technologies and protocols. However, FHIR includes all the best features and practices of previous HL7 standards.
For example, CDA and HL7 V3 both are based on RIM, and FHIR includes many components of CDA that are used for exchanging information about the patient.
The FHIR interoperability standard brings the concept of resources as the smallest exchange unit within healthcare, which becomes a solution to clinical and administrative issues. Resources can be extended to fit a specific use case, making the FHIR standard way more flexible in comparison to HL7 V2, V3, and CDA.
Pros and Cons of HL7 and FHIR?
FHIR is a part of the HL7’s family of healthcare standards, which is the best choice for ensuring interoperability in healthcare. However, implementation of the standards has its pros and cons that should be noted by healthcare stakeholders:
Pros:
- Wide Adoption: all HL7 standards, including FHIR, are globally recognized and ensure consistent data exchange.
- Backward Compatible: FHIR, compared to some previous standards by HL7, prioritizes backward compatibility, easing communication between older and newer systems.
- Specific Messaging: Tailored messaging solutions for various healthcare scenarios support standardized data exchange.
Cons:
- Legacy System Compatibility: Some legacy healthcare systems may not support FHIR, requiring hard work to ensure semantic interoperability in healthcare.
- Learning Curve: Despite accessibility, professionals may need time to learn these standards for effective implementation.
- Data Security: When implementing any healthcare standards, complying with data privacy regulations is a must to avoid catastrophic consequences of healthcare data breaches.
In summary, FHIR, among HL7 standards, excels in achieving semantic interoperability in healthcare. The choice between different HL7 standards should align with an organization’s needs.
Summary
We tried to demystify the false ideas about HL7 and FHIR and define the main difference between HL7 and FHIR. Here at Edenlab, the creators of the Kodjin Interoperability Suite, we focus on interoperability challenges. For more than seven years, we’ve been helping our customers solve healthcare data management issues.
Contact us if you want to know how to apply healthcare standards for your project. Our team will be pleased to meet your needs.
Frequently Asked Questions:
Why is FHIR better than HL7?
When choosing between FHIR integration or HL7, remember, there is no right or wrong choice between HL7 and FHIR. FHIR is a standard developed as HL7, as well as HL7 V2, V3, and other standards. FHIR is the newest standard that addresses healthcare interoperability problems, whereas HL7 V2 is used for communication within different systems in a healthcare establishment. Adopting FHIR is necessary for providers who want to comply with industry standards.
How is FHIR different from HL7?
The main difference between FHIR and HL7’s previous standards is the fast and simple implementation of FHIR resources compared to leveraging older standards and RESTful architecture support.
Why Is FHIR More Powerful Than HL7?
One reason FHIR is more powerful lies in the HL7 vs. FHIR format difference. The older HL7 standards support XML; the HL7 V2 format is based on pipe and hat encoding.
FHIR leverages modern web technologies, such as RESTful APIs, XML, and JSON. Widely-used open technologies enable more developers to create new healthcare IT solutions.
